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[57] ABSTRACT 

A method which allows implementation of the revocation of 
public-key certificates facilitates engineering of certificate 
revocation lists (CRLs). It solves the practical problem of 
CRLs potentially growing to unmanageable lengths by 
allowing CRLs to be segmented, based on size consider- 
ations or priority considerations related to revocation rea- 
sons. The method is used to distribute CRL information to 
users of certificate-based public-key systems. It Is also 
applied more generally to update any field in a certificate by 
reference to a secondary source of authenticated informa- 
tion. 

20 Claims, 4 Drawing Sheets 
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Fig 6 
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METHOD FOR EFFICIENT MANAGEMENT authority to ensure authenticity. In prior art, there is typically 

OF CERTIFICATE REVOCATION LISTS AND a single CRL associated with a certification authority, and 

UPDATE INFORMATION the CRL is updated at regular intervals (e.g. daily or 

weekly). Before extracting for use any public key from a 

FIELD OF INVENTION 5 certificate, prudent system users verify the signature on the 

The invention resides generally in the field of certificate certificate, that the current time precedes the expiry date 

management for pubu^-key cryr^ography. m r^cular.it is ***** « d * c serial number of the certificate in 

directed to a new method fox managing lists of revoked <J uestl0n does ** ***** 00 &e most recent Vihd W - 

certificates (certificate revocation lists), by partitioning them While ideally CRLs are small lists, they may potentially 

into smaller segments thereby allowing the maximum poten- 10 bc required to contain as many data items as the number of 

tial size of any one segment to be kept arbitrarily small, and outstanding certificates in a system. CRLs may grow large 

allowing efficient processing of lists according to revocation undo 1 many circumstances, e.g. in environments in which 

reasons. The invention applies more generally to allow certificates are revoked whenever personnel change jobs or 

update of or over-ride any field in a certificate by reference j° D roles. Large CRLs are a practical concern in systems 

to a secondary source of authenticated information. 15 supporting very large numbers of users. The size of CRLs is 

a particular concern in systems which require that CRLs be 

BACKGROUND OF THE INVENTION retrieved under the following conditions: from public direc- 

Public-key cryptography was introduced in 1976 (Diffie tones; over low-bandwidth channels; and/or on a frequent 

andHellnJw^^^ M basis.TI^ 

role in cryptographic solutions in the fidd of infennation 20 requiring Ujat several CRLs be checked m order to verify a 

sec^.US.p7No.4,m^ «»& ^ bhc ^ m mc ***** 

describes the technology. TOe basic idea is asfoUows. An J?*^ ™* * venfied * e * ^P*™ ^commenda- 

encryption algorithm, for example, is parameterized by a 00 

pair of related numbers, known as a private key and a public M OBJECTS OF THE INVENTION 

key. The public key known to everyone allows anyone to ft fa ^ objcct of ^ inycntion to ^ a 

encrypt a message for a specific intended reapien ; the method of or updating one or more data items in 

private key, known only to the intended recipient, allows a ceitificate 

only that individual to decrypt the message. _ . . * . ^. . A . . 

' . „ r.__^ . , L r , - « It is a further object of the invention to provide a method 

Public keys aretypcally distributed ^ means o f public- 30 whcRjb Monmiioil a public ^ ^ 

fay Recommendation XJ09:1993, hereaf- ^ ^ ta a location which can be determined 

ter X.509])^ A pubhe-key cer^cate^consists of a user s from me certificate. 

distinguished name, the public key to be associated with that . . . . ^ , . . ^. 

name and the digital rignature of a trusted third party * " vet *J«* «f * c u,ventl0n ^ Ptov.de a 

(commonly called fte oerdflcadoo authority or CA) which me*od of changing or updafang one or more daU, terns in 

bind, the name to the key. He certified usually also " a - T^T.h^^LE 

contains additional fields, deluding a validity pedal and a * c , ffia «" f 

serial number which uniquely distinguishes all certificates P rovidm « supplementary additional or updated information. 

from one certification authority. Effectively, the signature . * * "o*" <* invention to provide ^ mecha- 

serves as the trusted party's guarantee that the key is M msm for segmenting a certificate revocation list (CRL) into 

associated with the specified user. When other system users M •rtilrary number of smaller lists (CRL segments), so as 

successfully verify, using standard techniques (Rivcst, to «"»™ «L * I™*.** ^ «Uowmg the 

Shamir and Adleman 1978, hereafter [RSA]) that a certifi- 81ZC of Mch ""dividual CRL to be limited to any practical 

cate signature is correct, they may then be reasonably size - including P°«ibly only a single entry. 

assured that me public key in the certificate is authentic, and 4 , It is still a further object of the invention to provide an 

may safely proceed to use the public key within for appro- efficient method of selective processing and use of CRLs by 

priate cryptographic applications. U.S. Pat. No. 4,405,829 means of prioritized CRLs. 

(Rivest ct aL Sep. 20, 1983) describes the RSA technique. SUMMARY OF THE INVENTION 

Public key certificates are typically stored in public data- Briefly stated, the invention resides in a secure telecom- 
bases commonly referred to as directories [X.509]. The 50 mi wlcation system which includes a certification authority 
validity period in a certificate implies a default expiry date m ^ CQtJties or authorized by the 
of the certificate, after which time all users should treat fte certiflcation authatty for digitally issuing a certificate, 
binding between the key and user as invalid. If the certifi- According to ^ me Nation is directed to a 
cation authority which signed the certificate decides, for method of conveying additional information which specifies 
some reason (see below), to retract its endorsement of the 55 changes or updates over-riding data items within the certifi- 
public key prior to the normal expiry date, some method is ^ ^ wmpriscs ^ of: (i) extractin g from me 
followed to revoke the certificates. Reasons for revoking certificate accessing information which directly or indirectly 
certificates may include compromise or suspected compro- spedfies ^ me additional information may be obtained; 
misc of the corresponding private key, or early termination (u) verifving me authenticity of the additional information 
of the need for the key. «0 through standard techniques including digital signature veri- 

One method of certificate revocation involves use of a fixation; and (iii) using the verified information to modify or 

certificate revocation list or CRL (for example, see [JC509]). update the data items in the certificate. 

A CRL according to [X.509] consists of a list of zero or more 

pairs of data items, each pair indicating a certificate serial BRIEF DESCRIPTION OF THE DRAWINGS 

number and the time or date at which the certificate was 65 FIGS. 1 and 2 are illustrative examples of certificate and 

revoked. The composite list also includes a date of issue or CRL formats respectively, according to prior art e.g. 

validity period, and is digitally signed by the certification [X.509]; 
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FIGS. 3 and 4 are illustrative examples of a certificate and 
CRL respectively, according to embodiments of the inven- 
tion; 

FIG. 5 is an example illustrating the use of the method of 
segmented CRLs according to one embodiment of the 5 
invention; and 

FIGS. 6 and 7 represent parts of the embodiment of the 
invention used in certificate-using components and certifi- 
cate generating components of the system. ^ 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS OF THE INVENTION 

The invention consists of an implementahle mechanism 
motivated by, and meeting either (but preferably both) of the l5 
following objectives: 

1. to allow an upper limit to be imposed on the size of a 
CRL; 

2. to allow a distinction to be made between different 
instances of revoked certificates., based on the severity 20 
of the reasons for revocation. 

The second point of interest is to allow, for example, 
critical revocation lists (e.g. those certificates revoked for 
the reason of compromise of secret keying material) to 
potentially be distributed by different means, and at a 25 
different frequency, than less critical revocation lists. The 
invention meets both of the above objectives, as will be 
explained 

Different (possibly non -disjoint) subsets of the set of all 
certificates issued by one certification authority are assigned 30 
to different CRLs, by assigning to each certificate one or 
more CRL segments, the location of which (referred to as a 
CRL distribution point) is specified in the particular certifi- 
cate. A distribution point is a location which may serve as a 
readable data store (e.g. an entry in the directory), desig- 35 
nated to contain a CRL segment The segment associated 
with a particular certificate is designated to contain the 
revocation entry for that certificate (and possibly also for 
other certificates) should that certificate (ever) be revoked. 
In one extreme case of usage, each certificate may be 40 
associated with a distinct distribution point. More generally, 
each CRL segment is engineered to be able to accommodate 
a subset of the set of all certificates issued by a given CA. 
A particular certificate may also appear on two or more 
different CRL segments associated with the same revocation 45 
reasons, or an overlapping set of revocation reasons; this 
redundancy allows fault tolerance in the case that some CRL 
segments become unavailable, for unexpected reasons. 

Different CRLs (corresponding to specific sets of revo- 
cation reasons) arc used. Examples of reasons include com- 50 
promise of private or secret keys (which may imply a 
significant risk of private key misuse), and revocations 
resulting from routine binding terminations such as when 
keys are simply no longer needed (and which generally 
imply no significant risk of private key misuse). 55 

The invention pertains to public-key certificates where the 
public key may be of any type, including an encryption or 
signature public key [RSA], a key agreement public key 
(e.g. Difiie-Hellman key agreement [ DHJ), a public key used 
for entity authentication, etc. The invention also pertains to 60 
attribute certificates (see draft ANSI X930-3, November 
1994, Public Key Cryptography Using Irreversible Algo- 
rithms for the Financial Services Industry: Certificate Man- 
agement for DSA; proposed to become ANSI X9.57), which 
are used for certifying non-secret data ("attributes") other 65 
than public keys. An attribute certificate may be associated 
with a public-key certificate by including the serial number 



of the latter. Examples of items specified in attribute cer- 
tificates include information related to authorization and 
liability in financial transactions. 

In essence, the invention provides a method whereby 
additional information regarding a public key, for example 
its revocation status, can be found in a secondary location 
(one other than on the certificate itself) which can be 
determined from information within the certificate. The 
certificate proper can thus be viewed as a "fixed part" of the 
information about a public key. and the secondary location 
a "variable parr** which can be updated without updating 
individual certificates or the signatures thereon. The variable 
part should be signed by the same certification authority 
which signed the original certificate, or by an authority 
which has been authorized by this first authority; and before 
this data can be accepted as valid, this signature should be 
verified The advantage of this schema is the flexibility and 
efficiency offered by changing only the variable part, in 
particular when there are n certificates and m secondary 
parts, and it is expected that m is significantly less than n. 
Here a large number of certificates are associated with, and 
effectively share, a small number of secondary parts; and a 
particular secondary part may be associated with more than 
one certificate. 

The invention includes the application of the idea of the 
preceding paragraph to all items included in a certificate. 
The general invention is one of using a secondary list as a 
"delta" mechanism to update information in certificates. 
Revocation status as described above is a primary example. 
A second example is validity date. A third is a change to the 
distinguished name of an entity specified in a certificate. 
Similarly, other applications exist The general invention is 
of use in systems where certificate distribution or replace- 
ment is difficult, or less efficient man, updating a "delta" list 
This differs from, and is much more powerful than, a simpler 
idea hereafter called delta CRLs. A delta CRL is a list 
identifying the serial numbers of (only) those certificates 
which have been revoked subsequent to the date of the most 
recent previously issued such revocation list A delta CRL 
can be used to update a previously current CRL by adding 
the newly revoked certificates thereto Delta CRLs are 
specific to the property of revocation, pertain to a single 
CRL whose location is not explicitly specified, and apply 
universally to all certificates within a certificate system. 

As a further exposition of the application of this idea to 
validity dates, a field may be incorporated into a certificate 
indicating the location at which additional date-validity 
information regarding this certificate may be found. A list 
(validity-list or validity-segment, analogous to CRLs above) 
may then be used to specify a date replacing, or in addition 
to, the validity date on either a particular certificate 
(identified by serial number, for example), a subset of 
certificates, or all certificates associated with the segment in 
question. In the case of a validity date in both a certificate 
and on the validity-segment for the same certificate, a 
resolution policy for deciding the over-riding date is used 
(e.g. that in the validity-segment, or that which is earlier in 
time). As an illustrative example, a set of certificates with 
serial numbers 1 through 100 could all include fields speci- 
fying the same validity-segment X indicating an expiry date 
of Jan. 1 1996. If the relevant certification authority wishes 
to extend the validity period of all these certificates to Jan. 
1 1997, it could do so by creating and signing a single 
updated validity segment X made available at the specified 
location, and specifying in a single entry the new expiry date 
and "ALL" as the qualifier on the set of certificates to which 
the new date applies. 
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The invention may be used in conjunction with existing 
systems which use a single CRL. The latter may be viewed 
as a special case in which all certificates are associated with 
the same (single) CRL segment In general it is envisioned 
that CRLs are signed by the certification authority's single 5 
signature key, and distribution points do not have their own 
key pairs. In other embodiments of the invention separate 
keys might be used for different CRL segments* perhaps 
associated with different distribution points. 

The invention is most easily described relative to any iq 
existing certificate-based public-key system, and involves 
the inclusion of the following additional fields in the speci- 
fied data structures: 

1. in a certificate, a field (address _Jist) identifying one ox 
more particular CRL segments, and sufficient informa- is 
tion allowing these to be obtained; 

2. in a CRL, a composite field ({address, reason_codes} 
address (or equivalent information) where this CRL 
(now a CRL segment) is intended to be located, and the 
set of revocation reasons associated with this segment 20 

The address_Jist field is a list of values identifying, 
explicitly or implicitly, one or more distribution points at 
which a CRL associated with the certificate in question may 
be found. An application using the certificate may obtain 
from this location a CRL, to ascertain if the certificate in 25 
question has been revoked. 

In one embodiment this address _Jist contains a single 
entry, giving reference to a distribution point defined to 
contain any certificate revocation for this certificate, regard- 
less of the revocation reason. In another embodiment this 30 
field contains a list with multiple entries, the first being as 
above, and additional entries which respectively indicate 
distribution points at which reason-specific CRL segments 
may be found. A reason-specific CRL segment is a CRL 
segment restricted to contain entries corresponding to cer- 35 
tificates revoked for only a limited subset of the set of all 
defined revocation reasons (e.g. for the reason of compro- 
mise of a private key). In a further embodiment, the 
address_list field value embedded in a certificate is the 
one-way hash of a (typically longer) address_Jist value; this 40 
allows some savings in storage. 

Referring to the accompanying drawings, one preferred 
embodiment is illustrated in detail. FIGS. 1 and 2 show prior 
art certificate and CRL formats respectively. FIG. 3 and 4 
show certificate and CRL formats, respectively, according to 45 
embodiments of the invention which include added fields 
shown in bold. The added field in FIG. 3 is: address_Jisfc= 
{CRL„address, reason_codes}*. Here ***** indicates the 
one or more entries of the indicated form. CRL_address is 
a value indicating a location at which a CRL segment may 50 
be found A network address, filename address, database 
directory entry address, or the like can be used for this 
purpose. Reason_codes indicates the subset of revocation 
reasons for which certificates whose serial numbers on that 
CRL segment have been revoked; this may be a single 55 
reason, a set of two or more reasons, or a value denoting all 
reasons. 

In FIG. 4, a new field {address, reason_codes} is added. 
For a given CRL segment X, the first part of this new field 
specifies the distribution point at which X is intended to be go 
made available. One purpose of this field Is to prevent 
otherwise authentic CRL segments from being moved 
around, by malicious parties, from one distribution point to 
another, for example in the case the CRL segment at one 
distribution point site is empty, while at another is not An 65 
application using X should check that the location at which 
X is found matches that which is specified internally by the 
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address field within X itself. If a CRL segment is a reason 
specific CRL segment the revocation_list_entry of prior 
art becomes a revocation_entry which contains a new entry 
called *Tevocation__reason" in addition to serial number and 
revocation date. For example: 

revocation_entry={ serial _number, revocation_date. 
revocation_reason } 

FIGS. 5-7 are charts illustrating actions which will be 
taken by various components according to an embodiment 
of the invention. It should be noted that in FIG. 5, the only 
fields shown in CRLs are the CRL address and reasons 
codes, along with the list of {serial number, rea$on_codes} 
entries for revoked certificates on that list Also, only serial 
numbers and data allowing location of CRL segments are 
shown in certificates. 

In summing up, the major advantage of the invention is to 
be able to control, or engineer, the size of a CRL segment 
A further advantage is to allow different CRL segments to be 
consulted depending on the severity of the revocation 
reason, thereby allowing CRL segments to be classified and 
processed by prioritized reasons. 

What is claimed is: 

L In a secure telecommunication system which includes 
an authorization agent such as a certification authority and 
other entities authorized by said certification authority for 
digitally issuing a certificate, a method of conveying addi- 
tional information which alters actions taken by a system 
processing said certificate, comprising steps of: 

i) storing additional information at a plurality of data 
storage locations; 

ii) extracting from said certificate accessing information 
which specifies how said additional information is to be 
obtained; 

hi) verifying the authenticity of said additional informa- 
tion through digital verifying techniques such as digital 
signature verification; 

iv) processing said verified additional information 
obtained from any of the plurality of data storage 
locations; and 

v) performing on said certificate the action altered by the 
additional information. 

2. The method according to claim 1, wherein the addi- 
tional information is related to the validity of a certificate, 
conditions for the validity including any of certificate 
revocation, a validity period specified by a starting and 
ending date and other relevant information, and any alter- 
ation of such conditions. 

3. The method according to claim 2 wherein the validity 
conditions are verified by the use of CRLs. 

4. The method according to claim 3, wherein a CRL is 
segmented and a list of revoked certificates corresponding to 
a particular authorization agent is separated into at least one 
CRL segment whose content is stored in one of the plurality 
of data storage locations, and each certificate contains at 
least one location indicator which indicates associated CRL 
segment 

5. The method according to claim 4, wherein at least one 
CRL segment corresponds to at least one revocation reason. 

6. The method according to claim 5, wherein the location 
indicator specifies a field in an entry in a database. 

7. The method according to claim 5, wherein the certifi- 
cate is of the format as specified in X.509 and the location 
indicator is an additional field in the certificate. 

8. The method according to claim 5, wherein the format 
of CRLs and CRL segments is that specified in X.509 with 
an added field within the CRL itself specifying any of the 
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location indicator of the CRL segment and the reason codes 
associated with this particular CRL segment 

9. The method according to claim, wherein the certificate 
is a public-key certificate for any type of public key* 
including Diffie-Hellman public keys. 

10. The method according to claim 5, wherein the cer- 
tificate is for an attribute other than a public key. 

11. The method according to claim 5, wherein CRL 
segments at at least one distribution point are signed by any 
of a common certification authority key and segment keys 
authorized by the certification authority which issued the 
certificate. 

1Z The method according to claim 5, wherein a particular 
certificate appears on a plurality of different CRL segments 
associated with any of the same revocation reasons and an 
overlapping set of revocation reasons. 

13, The method according to claim 5 wherein a CRL 
segment is indicated indirectly from information embedded 
in the certificate and the certificate includes a compressed 
representation such as hash of a more complete specification 
of information, linkable thereto. 

14. The method according to claim 5 wherein a CRL 
segment is indicated by an explicit address. 
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15. The method according to claim 5 wherein the method 
of indicating a CRL segment can be determined indirectly 
from information embedded in the certificate, the embedded 
information being represented by a compressed 

s representation, such as the result of one-way hash. 

16. The method according to claim 5, wherein at least one 
revocation reason is specified in the CRL segment 

17. The method according to claim 6, wherein the data- 
base is a directory and the entry includes a CRL attribute of 

10 an entry in an X^09directory. 

18. The method according to claim 5, wherein the cer- 
tificate is of the format similar to that specified in X.509 and 
the location indicator is an additional field in the certificate. 

19. The method according to claim 5, wherein the format 
15 of CRLs and CRL segments is similar to that specified in 

X.509, with an added field within the CRL itself specifying 
any of the location of the CRL segment and the reason codes 
associated with this particular CRL segment. 

20. The method according to claim 14 wherein an explicit 
20 address is any of a network address, filename address, and 

database directory entry address. 

***** 
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